Express Mailing Label No. : ET 1 5 5 1 69803US PATENT APPLICATION 

Docket No.: 1200.2. 18 
IBM Docket No.:BLD92000047USl 



UNITED STATES PATENT APPLICATION 

of 

Stephen D. Hanna 
and 

Howard C. Jackson 
for 

COMPRESSED DATA TRANSMISSION OVER A 
PLURALITY OF TRANSMISSION PATHS 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 



COMPRESSED DATA TRANSMISSION OVER 
A PLURALITY OF TRANSMISSION PATHS 



BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

This invention relates to the field of raster based graphic generation and, more 
specifically, to the transmission of data from a random access memory associated with 
raster object data to a raster object data processing module. 

2. The Relevant Art 

Raster Image Processors generally consist of hardware and software that converts 
vector graphics into raster (bitmapped) images. These processors are used in page 
printers, phototypesetters, and electrostatic plotters. Raster image processing can be of 
considerable duration, especially when large images are being printed. 

In the current state of the art, printer systems receive compressed data of some 
format from a host over a system bus, such as a PCI bus. The compressed data is stored 
in memory that resides on a circuit board between the host and the printer itself. Once the 
data has been received into memory, it is sent to a decompressor and from the 
decompressor, to the printer. The path from the host to the printer is known as a data 
pipeline. 

When large print operations, or jobs, are sent through the data pipeline for 
printing, the delay in processing and printing the data can be substantial. This delay can 
be caused by a number of factors such as decompression schemes, data bottlenecks, 
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printer speed and memory speed. Data bottlenecks occur when data is sitting idle in the 
pipeline waiting to be transmitted to the next stage in the pipeline. While the data is idle, 
precious processing time is being wasted. 

Often, in current art printing systems, different data types are assigned specific 
buses upon which they may be transmitted. For instance, a typical print job may contain 
JPEG image data, Linework image data, and Linework control data, with each data type 
being transmitted over its own, individual bus to the correct processor. Often, when one 
data type dominates a print job, the bus for that data type operates at 90-100 percent 
capacity, while the other two buses in the system run at perhaps 10% capacity. Due to 
the large amount of data being transmitted on a single bus, the data type that is 
transmitted on that bus begins to stack up in the pipeline and causes a data bottleneck. 
The bottleneck, in turn, slows down the operation of the printer or other raster image 
processing device. 

From the above discussion, it can be seen that it would be beneficial to 
improve the performance of printing systems by providing a system and method for data 
transmission that is capable of utilizing all the available bus space in a print system to 
transmit print data more quickly to a high capacity print engine. 
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OBJECTS AND BRIEF SUMMARY OF THE INVENTION 

The data transmission system of the present invention has been developed in 
response to the present state of the art, and in particular, in response to the problems and 
needs in the art that have not yet been fully solved by currently available data 
transmission systems. Accordingly, it is an overall object of the present invention to 
provide a data transmission system that overcomes many or all of the above-discussed 
shortcomings in the art. 

To achieve the foregoing object, and in accordance with the invention as 
embodied and broadly described herein in the preferred embodiment, an improved data 
decompression system and method are provided. 

The data transmission method of the present invention may include receiving a 
plurality of parallel data streams of compressed print data each having a plurality of bytes 
into a storage stage such as a memory or FIFO. The memory or FIFO is fed in groups of 
bytes as space opens up. The data waits in the memory or FIFO until a request for the 
data is received from the decompression system. 

When the memory receives the data request, it transmits the appropriate type of 
data to be decompressed. The requested data is then transmitted over one of a plurality 
of available buses between the memory system and the appropriate decompressor within 
the decompression system. 

When the request for data is generated, an identification pattern for the data type being 
requested is also generated and transmitted simultaneously with the data request. 

The data identification pattern within the request is evaluated by the 
memory and the appropriate data type is then transmitted over any one of a plurality of 
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1 buses located between the memory system and the decompression system, depending 

2 upon availability of the buses. When the data is transmitted from the memory system to 

3 the decompression system, the identification pattern is transmitted immediately preceding 

4 the data. When the data identification pattern is transmitted by the decompression 

5 system, the memory or FIFO evaluates the pattern and routes the data following the 

6 pattern to the appropriate decompression system. The data is then decompressed in an 

7 appropriate manner, and is transmitted to other downstream elements of the printing 

8 system. 

9 These and other objects, features, and advantages of the present invention will 

10 become more fully apparent from the following description and appended claims, or may be 

1 1 learned by the practice of the invention as set forth hereinafter. 
12 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 The present invention is illustrated by way of example, and not by way of 

3 limitation, in the figures of the accompanying drawings and in which like reference 

4 numerals refer to similar elements and in which: 

5 Figure 1 is a schematic block diagram illustrating one embodiment of a printer 

6 system that uses data transmission techniques for the transmission of compressed print 

7 data. 

8 Figure 2 is a schematic block diagram that illustrates one embodiment of a color 

9 printing system. 

10 Figure 3 is a schematic block diagram illustrating one embodiment of a color 

1 1 interface card. 

12 Figure 4 is a schematic block diagram illustrating one embodiment of a data 

1 3 processing module of the present invention. 

14 Figure 5 is a schematic flow chart diagram illustrating one embodiment of a data 

1 5 transmission method for use with the present invention. 

16 Figure 6 is a schematic flow chart diagram illustrating one embodiment of a 

1 7 handshaking routine for use with the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figure 1 illustrates one embodiment of a data printing system suitable for 
implementing the present invention. The data printing system 100 includes a host 102, a 
print controller 104, and a print engine 108. The data printing system 100 is configured 
to transmit data from the host 102 to be printed by the print engine 108. The host 102 
may be any type of computer system, including for example, a laptop computer, a 
desktop computer, a workstation, a server, and a mainframe. Data and control signals 
transmitted by the host 102 are coupled to the print controller 104 on interfaces 1 14 and 
116, respectively. A software compression module 106 compresses images received into 
the print controller 104 from the host 102. The images are preferably rasterized before 
being compressed. Some images may come previously compressed. 

The print controller 104 generally contains microcode to construct an image to be 
printed by the print engine 108. The print image is digitally formed in the page memory 
of the print controller 104 in a format required by the print engine 108 to generate an 
image. In one embodiment of the present invention, the print controller 104 is a reduced 
instruction set (RISC) microprocessor. In other embodiments the print controller 104 
may have other types of architectures such as, for example, a complex instruction set 
(CISC) architecture. Print controllers are well known in the art, and consequently, it is 
not necessary to provide a detailed description of the internal components and operation 
of the print controller 104. 

In one embodiment, the print engine 108 is a four color (CYMK) LED printer that 
functions to generate a visible image from digital data residing in the page memory of the 
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print controller 104. In a further embodiment, the print engine 108 is a multiple beam color 
laser printer. 

Printer systems such as the printer system 100 shown in Figure 1 are generally 
configured to conduct a series of hardware and software operations on digital print data in 
preparation for printing. These hardware and software operations are often referred to as a 
pipeline. The digital print data is used by the print engine 108 to form a print image on a 
printing surface. An area of the print surface on which the image is formed is referred to as 
a picture element (PEL or pixel). One scan of the LEDs across the print surface forms a row 
of pixels referred to as a scan row. The print image is formed by multiple scan rows being 
successively formed on the print surface. 

Often, the image is further broken up into objects, with a plurality of objects per 
page. The types of data passing through the pipeline generally include text, graphics, 
images and combinations of these elements. The density of dot placement in modern 
printers is constantly increasing, particularly with color printing that requires additional 
bits per PEL over monochrome printing. The time required for the data pipeline to 
transmit the data from the host computer 102 to the print engine 108 is correspondingly 
increasing. To fully utilize the increasing speed capabilities of print engines, the pipeline 
of a printer system must be able to transfer data fast enough to supply a continuous 
stream of data to the print engine 108 in order to allow the print engine 108 to print data 
continuously. 

The depicted embodiment of a printer system 100 utilizes software compression 
106 and hardware decompression 1 10 to compress and decompress print data in such a 
manner that it may be transferred to the print engine 108 as a high volume, continuous 
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data stream. Data compression refers to a process that attempts to convert data in a given 
format into an alternative format or formats requiring less space and bandwidth than the 
original. One example of a data compression format is JPEG. By using data 
compression and decompression in printer systems such as the printer system 100, it is 
possible to transmit data quickly enough to keep the print engine 108 printing data 
continuously. 

One further compression technique, referred to as run length encoding, converts a 
data stream of continuous pixel data into a code for transmission. In so doing, repeated 
identical bytes of the data stream frequently occur and can be passed in compressed code. 
For example, using one run length compression method, the pixel data line 
"aaaabbbbbbbcccccdd" is converted into the coded data "a4b7c5d2." The coded data 
consists of bytes of pixel information (a, b, c and d) and the number of those bytes that 
are the same (4, 7, 5 and 1). Each byte contains 8 bits of pixel information. 

Once the print data is rasterized and compressed in the print controller 104, the 
print data is transmitted to the print engine 108. In the depicted embodiment, the print 
data is transported across a PCI bus interface. Upon arriving at the print engine 1 08, the 
print data is decompressed using the hardware decompression 110. When the data has 
been successfully decompressed, it is transferred to the print heads 1 12 for printing. 

Figure 2 illustrates one embodiment of a printing system 200 suitable for 
incorporating the data transmission system and method of the present invention. In one 
embodiment, the printing system 200 includes a print controller 104, a plurality of color 
interface cards (CIC) 208, 210, 212, 214 (collectively 220), and a print engine 108. The 
print controller 104 may include a rasterizer 204. The rasterizer 204 preferably makes a 
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raster image of print data, then compresses the print data or part thereof as objects, and 
transmits the compressed print data to the CICs 220 via a bus 206 such as a PCI bus. In 
one embodiment, at least a portion of the print data is compressed using run length 
encoding (RLE), and the decompression thereof is substantially lossless. The print data is 
also transmitted in other compressed formats such as JPEG that do not decompress 
losslessly. 

In one embodiment, the rasterizer 204 processes an input stream of print data that 
describes what is to be printed by the print engine 108. The rasterizer 204 converts input 
print data into bitmaps that are in a format that is compatible with the hardware of the 
CIC cards 220. The print data may be organized into a plurality of objects of text and/or 
images on a print sheet originally stored in the print controller 104. The print data is then 
compressed so that it may be stored and later transmitted to the CICs 220 over an 
interface such as the PCI bus interface using a minimum of bandwidth. 

The output of the rasterizer 204 allows the CICs 220 to render the objects in the 
compressed data stream by driving the output devices, such as a print head 1 12 of Figure 
1 containing lasers or LEDs. In an alternative embodiment, the method described herein 
may be used in other output devices of data networks to losslessly compress/decompress 
objects and render the objects on a screen, for instance, by driving output devices such as 
LCD arrays within a computer monitor. 

In one embodiment, each CIC 220 can decompress any or all of three data types: 
Continuous Tone (CT), Linework (LW), or Linework control (LWC). The CICs assigned 
to decompress LW and LWC data perform a lossless decompression of the compressed 
stream of LW and LWC data, while the CICs assigned to decompress the CT data may 
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perform a lossy decompression of the compressed stream of CT print data. The 
decompressed data is then transmitted via print head signals 216 to feed the print heads 
112 of Figure 1. The print head signals 216 preferably transmit various types of 
decompressed data from the CICs 220. For example, continuous tone (CT) data, line 
work (LW) data and line work control (LWC) data are transmitted as bit maps through 
the print head signals 216. When the print engine 108 receives a print head signal 216, 
the signal may contain any or all of the three data types merged together. 

In one embodiment, a plurality of CICs 220 are multiplexed at the print engine 
108 to provide a high capacity print engine with a constant flow of decompressed print 
data. In the depicted embodiment, four CICs 220 decompress print data in parallel. The 
CICs 220 are preferably located together in a modular bus interface card, such as a RISC 
card, local to the print engine 220. 

In the preferred embodiment, two colors are supported per CIC card 220. Thus, 
for example, in a printer printing four colors in duplex, four CIC cards are required. 

Figure 3 is a schematic block diagram illustrating one embodiment of a data 
transmission and processing system 300 of the present invention. In the depicted 
embodiment, the data transmission and processing system 300 comprises a color interface 
card (CIC) 220 of Figure 2. The CIC 220 includes a PCI adapter 301, a memory card 
303, an interface 322, a decompression module 302 and a merge and screen module 308. 
The PCI adaptor 301 is preferably configured to receive data streams of compressed print 
data using the PCI interface and to pass those data streams into the memory card 303. A 
handshaking control module 307 is preferably provided to request the data from the PCI 
adaptor 301 as the decompression module 302 needs it. 
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As depicted, the memory card 303 (given herein as one example of a memory 
stage) comprises aplurality of RAM memory modules 310, 312, 314 and a plurality of 
FIFO buffers 316, 318, 320. The data streams received by the PCI adaptor 301 are 
passed into one of the RAM modules 310, 312, 314 depending on the type of print data in 
the particular data stream. In the depicted embodiment, print data compressed using run 
length encoding (e.g., LW data) is transferred in to the RAM module 310, while control 
data (e.g., LWC data) for that print data is passed to the RAM module 312. Print data 
compressed using a continuous tone format such as JPEG is transferred to the RAM 
module 314. The respective print data is then passed in to the respective FIFO buffers 
3 16, 3 1 8, and 320. Once the data has been passed to the FIFO buffers, it awaits a data 
request from the data processing module 306 via the handshaking control module 307. 

When a data request has been received from the data processing module 306, the 
handshaking control module 307 makes the data type corresponding to the data request 
available at the output of the appropriate FIFO buffer. The data requested is then 
transmitted to the data processing module 306 of the decompression module 302 via the 
interface 322. The interface 322 is preferably configured with a plurality of internal 
buses, including one that is dedicated to the transmission of CT data and two that may 
used to transmit either LW or LWC data. The data processing module 306 receives the 
data via the transmission paths 334a, 334b for LW and LWC data and via the 
transmission path 336 for CT data. The data processing module 306 then decompresses 
the requested data and transmits it through the output FIFOs 324 and 325 to the merge 
and screen module 308. 
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For example, when the data processing module 306 requests Linework (LW) data, 
the handshaking control module 307 requests the data from the host and stores it in the 
LW RAM memory 310. The data is then transferred to the LW FIFO 3 1 6 when the FIFO 
316 has space to admit the data. The handshaking control module 307 then enables the 
output of the FIFO 316 and places the data on either the LW/LWC bus 327 or the 
LW/LWC bus 326 depending upon which bus the data was requested across by the data 
processing module 306. If neither bus is busy, the data processing module 306 adheres to 
a set or random procedure to determine which bus the data is transmitted across. The 
data is then transmitted via the selected bus to the data processing module 306, which 
then decompresses the data. 

The merge and screen module 308 then merges the decompressed print data, 
screens the print data, and subsequently transmits the print data to the print engine 108 of 
Figure 1 . The decompressed print data is then fed into the print heads 112. In one 
embodiment, a plurality (eight in the depicted embodiment) of concurrently 
decompressed print data streams are transmitted to the print engine 108 at once, 
preferably through a plurality (e.g., two) of fiber channel interfaces. 

In one preferred embodiment, each CIC 220 comprises a plurality of 
decompression modules identical to the depicted decompression module 302. In one 
embodiment, each CIC 220 contains two such modules 302. Each CIC 220 also 
preferably comprises a corresponding plurality of merge and screen modules identical to 
the depicted merge and screen module 308. The existence of a plurality of 
decompression modules and merge and screen modules per each CIC 220 allows each 
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CIC 220 to decompress a plurality of incoming data streams simultaneously in a parallel 
fashion. 

While in the depicted embodiment only a single linework decompressor 356 and a 
single linework control decompressor 358 are shown, the data processing module 306 is 
in one embodiment comprised of four linework decompressors 356 with four associated 
FIFOs 350, and four linework control decompressors 358 with four associated FIFOs 
352. Thus up to four linework decompressors and four linework control decompressors 
may simultaneously request data across the two buses 334a and 334b. The data 
processing module 306 coordinates those requests and passes up to two requests on to the 
memory card 303, one request per bus. 

Figure 4 illustrates one embodiment of a data processing module 306 configured 
to receive and process the data requested from the memory card 303 of Figure 3 through 
the handshaking control module 307 of Figure 3. The data processing module 306 
comprises a set of input FIFO buffers 350, 352, 354 a Linework decompressor 356, a 
Linework control decompressor 358, and a continuous tone decompressor 360. When the 
data processing module 306 requests the compressed data from the memory card 303 of 
Figure 3, the handshaking control module 307 enables the output of the appropriate FIFO 
316,318, or 320. 

Once the appropriate FIFO 316, 318, or 320 has been enabled, the handshaking 
control module 307 determines which bus to place the data on. If the data is Linework or 
Linework Control data, it may be placed on either of the LW/LWC buses 326 and 327, 
according to which bus the bus control module 306 requested the data to be transmitted 
across. The data processing module 306 controls which bus 326, 327 the data is 
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transmitted across. If both LW/LWC buses 326 and 327 are not busy, the data processing 
module 306 arbitrarily chooses one of the LW/LWC buses 326 and 327 to use. Of 
course, a standard procedure such as an alternating scheme could also be used to select 
which of the buses 326, 327 to place the data on when both buses are not busy. The 
LW/LWC data is then transmitted to the data processing module 306 via the transmission 
paths 334a or 334b. 

Continuous Tone data is always transmitted via the CT bus 328. Accordingly, 
when CT data is requested, the CT data is transmitted to the data processing module 306 
via the CT bus 328 and the transmission path 336. 

If the data being received comprises Linework data, the data is routed through the 
FIFO buffer 350 into the Linework decompressor 356. The Linework decompressor 356 
decompresses the compressed print data and transmits it to the output FIFO 324 of Figure 
3 via transmission line 330. Likewise, if the data being received comprises Linework 
control data, the compressed data is routed through FIFO buffer 352 into the Linework 
control decompressor 358. The Linework control data is then decompressed and 
transmitted to the output FIFO 324 of Figure 3 via the transmission path 330. If the data 
received is continuous tone data, such as a JPEG compressed image, the compressed data 
is routed through the FIFO 354 into the continuous tone decompressor 360. The 
continuous tone decompressor 360 then decompresses the data and transmits it to the 
output FIFO 325 of Figure 3 via the transmission path 332. 

The use of the output FIFO buffers 324, 325 of Figure 3 allows the data from the 
Linework decompressor 356, the Linework control decompressor 358 and the continuous 
tone decompressor 360 to be simultaneously loaded into the merge and screen module 
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308 of Figure 3. This merge and screen operation allows one area of an image to contain 
multiple data types. Each may be compressed, transmitted and decompressed separately, 
but may be printed simultaneously through the use of the output FIFO buffers 324, 325 of 
Figure 3 and the merge and screen module 308 of Figure 3. 

The invention preferably also utilizes two bus request lines, one for bus 326 and 
one for bus 327 to communicate which linework or linework control objects are needed. 
A bit on each bus is used to designate whether the requested objects are linework or 

linework control data. 

The present invention provides advantages over the prior art. These advantages 
result from the fact that the memory components within the memory card 303 of Figure 3 
are capable of operating at a rate twice as fast as the decompressors 356, 358, 360 of 
Figure 4. In addition, typical print jobs tend to involve either large amounts of linework 
data (LWD) data and small amounts of linework control data (LWC data) or vice- versa, 
but generally not equal amounts of both types of data. 

In prior art printers, a data processing module (such as the data processing module 
306) might request an object X of LWD (for example) from the handshake control 
module 307. Even though the LWC decompressor and corresponding interface circuitry 
is capable of simultaneously requesting and receiving LWC data, this would not occur 
under the prior art because the job consisted primarily of LWD. Therefore, the memory 
would sit and wait for the LWD decompressor and interface circuitry to process the 
current data and request additional data, while the LWC decompressor sat idle. A similar 
situation existed for jobs that consisted primarily of LWC data. In such jobs, the LWD 
decompressor sat idle for large amounts of time. 
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Under the present invention, the data processing module 306 may now request 
and receive a plurality of objects of the same type simultaneously. For example, the data 
processing module 306 may request an object X of LWD and an object Y of LWD more 
or less simultaneously from the memory system handshake control module 307. The 
object Y request would in one example under embodiments of the present invention 
specify the LWC bus. The memory system would then start extracting data from the 
LWD memory and steer the object X data to the LWD bus and the object Y data to the 
LWC bus. The data would therefore be delivered to the decompressors at twice the rate 
as the prior art implementation. 

Figure 5 is a schematic flow chart diagram illustrating one embodiment of a 
process 500 that may be conducted by the CIC 220 of Figure 3 to transmit a plurality of 
data types over any one of a plurality of available data buses. In the depicted 
embodiment, the process 500 is in an idle state 502 when printing jobs are not being 
processed. When the host 102 of Figure 1 initializes a printing job, the CIC 220 of Figure 
3 prefetches the data associated with that print job into the memory 315 of Figure 3 in a 
step 504. While the data is being prefetched into the memory 315, the CIC 220 processes 
the header information of the data to be printed in a step 506. The processing of the 
headers in the step 506 allows the decompressor 356, 358, and 360 within the data 
processing module 306 to know the correct manner in which to request the data for 
decompression from the memory. Once the data has been prefetched into the memory in 
the step 504 and the headers have been processed in the step 506, the data processing 
module 306 begins to request data to be decompressed. 
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Each request that the data processing module 306 makes is preferably for a 
specific data type, either Linework (LW), Linework Control (LWC), or continuous tone 
(CT). The handshaking control module 307 is configured to evaluate the data type 
requested by the data processing module 306 and enable the appropriate input FIFO in a 
step 510. Once the appropriate input FIFO has been enabled in the step 510, the 
handshaking control module 307 selects the bus to place the data on in a step 512. If the 
data requested is CT data, the data is always placed upon the dedicated CT bus 328 in a 
step 514. However, if either LW or LWC data is requested, either one the LW/LWC 
buses 326 and 327 may be used to transmit the data. The data processing module 306 
evaluates how busy each of the LW/LWC buses 326 and 327 are and requests the data to 
be transmitted across the least busy bus in the step 514. 

Once the data has been placed upon the appropriate bus in the step 514, it is then 
transmitted to the data processing module and decompressed by the appropriate 
decompressor in a step 516. Once the data has been decompressed in the step 516, it is 
transmitted to the output FIFOs 324 and 325 in a step 518. The data is held in the input 
FIFOs 324 and 325 until all the data for an object has been decompressed and then the 
data is transmitted to the merge and screen module 308. When the data arrives at the 
merge and screen module 308, the different types of decompressed data (LW, LWC, and 
CT are merged together in a step 520. Once the data has been merged together, it is 
transmitted to the print engine 108 in a step 522. 

Throughout the cycle of the data transmission process 500, the handshaking 
control module monitors the input data stream and input FIFOs as outlined in the process 
600 of Figure 6. When no print jobs are being processed, the handshaking control 
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module 307 is in an idle state as shown in a step 602. When a print job is begun, the data 
processing module 306 sends a request to the handshaking control module 307 for data 
based upon the evaluation of the file headers as shown as part of the process 500. The 
handshaking control module 307 receives the request in a step 604 and requests the image 
data from the host through the PCI adaptor 301 in a step 606. 

As the data requested from the PCI adaptor 301 in the step 606 is being received, 
the handshaking control module 307 places the data into the correct input FIFO. For 
example if the data processing module 306 requested Linework data, the handshaking 
control module would place the Linework data into the FIFO 316 associated with 
Linework data. As the data stream comes into the CIC 220 from the host 102, the 
handshaking control module continuously checks to verify that all of the input FIFOs 
316, 318, and 320 are not empty in a step 610. Once any one of the input FIFOs 316, 318 
or 320 becomes empty, the printing process comes to a halt and the handshaking control 
module 307 returns to an idle state of the step 602. 

If, however, all of the input FIFOs are not empty, as determined in the step 610, 
the handshaking control module 307 monitors the fullness of each individual FIFO in a 
step 612. When data is received from the PCI adaptor in the step 606 it is directed to the 
FIFO that has the least amount of data in the step 614. This process ensures that all of the 
FIFOs 316, 318, 320 remain full until the end of the print process. 

In the foregoing specification, the invention has been described with reference to 
specific exemplary embodiments thereof. It will, however, be evident that various 
modifications and changes may be made thereto without departing from the broader spirit 
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and scope of the invention as set forth in the appended claims. The specification and 
drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. 
What is claimed is: 
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